Working with developers isn’t just about shipping features or moving tasks across a board.
It’s about trust, structure, empathy — and knowing when to get out of the way.
As a project manager, you’re the bridge between technical execution and business outcomes.
And if you're working with developers, you know: this job is part choreography, part diplomacy.
Here’s what I’ve learned (often the hard way) about collaborating with dev teams — and making the work not only efficient but human.
The most powerful thing you can do? Build a space where developers feel psychologically safe — like actual stakeholders, not outsourced executors.
That means:
Involving them in ideation, not just execution
Listening deeply (not just waiting to speak)
Recognizing their expertise without micromanaging
You can’t fake respect. Developers know when they’re being treated as code monkeys. And they check out fast when that happens.
Your job is to protect the team from chaos — not to add to it.
Keep stakeholders from scope-creeping directly into devs’ DMs
Maintain clear boundaries between business needs and team execution
Prioritize clarity over control
Yes, you’ll feel pressure from above. But that’s not your team’s burden. It’s yours to absorb — and translate into productive, actionable plans.
Daily standups, sprint planning, retros — they work for a reason. Structure creates freedom. Clear expectations reduce stress.
Here’s what I stick to:
10-minute daily standups
No check-ins outside that unless something’s blocking progress
Weekly reviews with async notes on Slack or Notion
Monthly retros to improve the how, not just the what
Micro-checking in? It’s not helpful. Focus on outcomes, not keystrokes.
If something goes wrong, don’t panic. Don’t blame.
Take a breath. Then ask:
What happened?
When did we know?
What can we learn?
Panic spirals are contagious. Calm is, too.
Slack is great — until it isn’t. Developers can’t chase updates across five different tools.
Stick to one centralized hub for:
Documentation (Confluence, Notion, etc.)
Task tracking (JIRA, Asana, Trello)
Status communication
My rule of thumb? If it’s not written down, it doesn’t exist.
Some stakeholders will try to skip the line and message your devs directly.
Here’s how I handle it:
Gently redirect them to me
Invite them into structured feedback loops (like testing new versions)
Give them visibility, but not control
They want to feel included. That’s fair. Just make sure it happens on your terms — not in a way that derails your team.
In-office, you can solve things next to the coffee machine. Remote? Not so much.
Documentation becomes your best ally.
Record meeting notes
Track decision history
Clarify “what done looks like”
Documentation isn’t busywork — it’s clarity at scale.
Burnout isn’t about long hours. It’s about long hours of ambiguity, pressure, and feeling alone.
Your job is to:
Give context
Break down big goals into achievable chunks
Celebrate progress, not just results
If your team trusts you to have their back, they’ll go further than you expect.
JIRA, Asana, Trello — they’re all fine. I prefer JIRA because of its integration with Confluence and Git. But honestly?
A mediocre tool + clear communication > the best tool + team confusion.
Pick what fits your team’s rhythm. And don’t be afraid to switch if it’s not working.
The best developers I’ve worked with? They aren’t just great at code.
They’re great at communication, collaboration, and thinking in systems.
And the best PMs I’ve met? They aren’t just organizers.
They’re connectors.
Soft skills are the hard skills when building real teams.
Managing developers isn’t about controlling them. It’s about enabling them — and learning alongside them.
The goal isn’t just velocity or clean burndown charts.
It’s building a culture where technical teams thrive, trust each other, and solve real problems together.
You’re not just shipping products. You’re shaping how people work together.
And that’s where the real impact happens.